home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-bgp-idrp-usage-00.txt < prev    next >
Text File  |  1993-10-18  |  55KB  |  1,295 lines
  1.  
  2. Network Working Group                                         Y. Rekhter
  3. Request for Comments: DRAFT       T.J. Watson Research Center, IBM Corp.
  4. draft-ietf-bgp-idrp-idrp-usage-00.txt                        S. Hares
  5.                                                              Merit, Inc.
  6.                                                                  Editors
  7.                                                           September 1993
  8.  
  9.  
  10.  
  11. Application of the Border Gateway Protocol and IDRP for IP in the Internet
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.  
  17.    This document, together with its companion documents, "A Border
  18.    Gateway Gateway Protocol 4 (BGP-4)" and "IDRP for IP", defines an
  19.    inter-autonomous system routing protocol for the Internet. This RFC
  20.    specifies an IAB standards track protocol for the Internet community,
  21.    and requests discussion and suggestions for improvements.  Please
  22.    refer to the current edition of the "IAB Official Protocol Standards"
  23.    for the standardization state and status of this protocol.
  24.    Distribution of this document is unlimited.
  25.  
  26.    This document is an Internet Draft. Internet Drafts are working
  27.    documents of the Internet Engineering Task Force (IETF), its Areas,
  28.    and its Working Groups. Note that other groups may also distribute
  29.    working documents as Internet Drafts.
  30.  
  31.    Internet Drafts are draft documents valid for a maximum of six
  32.    months. Internet Drafts may be updated, replaced, or obsoleted by
  33.    other documents at any time. It is not appropriate to use Internet
  34.    Drafts as reference material or to cite them other than as a "working
  35.    draft" or "work in progress".
  36.  
  37.  
  38. Abstract
  39.  
  40.  
  41.    This document, together with its companion documents, "A Border
  42.    Gateway Protocol 4 (BGP-4)" and "IDRP for IP", define an inter-
  43.    autonomous system routing protocol for the Internet.  "A Border
  44.    Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification.
  45.    "IDRP for IP" defines the use of IDRP for IP in the Internet. The
  46.    IDRP specification [6] defines the IDRP protocol. This document
  47.    describes the usage of the BGP and IDRP for IP in the Internet.
  48.  
  49.    Information about the progress of BGP can be monitored and/or
  50.    reported on the BGP mailing list (bgp@ans.net).  Information about
  51.    the progress of IDRP for IP can be monitored and/or reported on the
  52.    IDRP for IP mailing list (idrp-for-ip@merit.edu).
  53.  
  54.  
  55.  
  56. Expiration Date March 1994                              [Page 1]
  57.  
  58.  
  59. INTERNET DRAFT                                            September 1993
  60. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  61.  
  62. Acknowledgements
  63.  
  64.  
  65.    This document was originally published as RFC 1164 in June 1990,
  66.    jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
  67.    (Merit), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
  68.    (Merit).
  69.  
  70.    The following people also made key contributions to RFC 1164 -- Guy
  71.    Almes (ANS, then at Rice University), Kirk Lougheed (cisco Systems),
  72.    Hans- Werner Braun (SDSC, then at Merit), and Sue Hares (Merit).
  73.  
  74.    We would like to explicitly thank Bob Braden (ISI) for the review of
  75.    the previous version of this document.
  76.  
  77.    This updated version of the document was the product of the IETF BGP
  78.    Working Group with Phill Gross (ANS) and Yakov Rekhter (IBM) as
  79.    editors. Finally, the current version of the document covers the
  80.    usage of both BGP and IDRP for IP. The document is the product of
  81.    both the IETF BGP and IDRP for IP Working Groups with Susan Hares
  82.    (Merit, Inc.) and Yakov Rekhter (IBM) as editors.
  83.  
  84.    John Moy (Proteon) contributed Section 7 "Required set of supported
  85.    routing policies".
  86.  
  87.    Scott Brim (Cornell University) contributed the basis for Section 8
  88.    "Interaction with other exterior routing protocols".
  89.  
  90.    Most of the text in Section 9 was contributed by Gerry Meyer
  91.    (Spider).
  92.  
  93.    John Scudder (Merit) contributed bits of text throughout and did
  94.    proofreading and editing of several drafts of the document.
  95.  
  96.    Parts of the Introduction were taken almost verbatim from [3].
  97.  
  98.    We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco
  99.    Systems) for their review and comments on the previous version of the
  100.    document.
  101.  
  102. 1. Introduction
  103.  
  104.    This memo describes the use of the Border Gateway Protocol (BGP) and
  105.    "IDRP for IP" in the Internet environment.  IDRP and BGP are inter-
  106.    Autonomous System routing protocols.  IDRP and BGP have common roots
  107.    in version 2 of BGP.  However, IDRP has been standardized within ISO
  108.    as a multi-protocol inter-domain routing protocol.  IDRP for IP and
  109.    BGP-4 can be considered, for the most part, interchangeable.  IDRP
  110.    has a few additional features, and some minor differences in
  111.    encoding.  The usage of these additional features will be discussed
  112.    in Section 10.
  113.  
  114.    Hereafter in this memo, "BGP" will refer to both BGP-4 and IDRP for
  115.    IP.  BGP-4 will refer only to version 4 of BGP, and IDRP will refer
  116.  
  117.  
  118. Expiration Date March 1994                              [Page 2]
  119.  
  120.  
  121. INTERNET DRAFT                                            September 1993
  122. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  123.  
  124.  
  125.    to only the IDRP for IP protocol.
  126.  
  127.    The network reachability information exchanged via BGP provides
  128.    sufficient information to detect routing loops and enforce routing
  129.    decisions based on performance preference and policy constraints as
  130.    outlined in RFC 1104 [2]. In particular, BGP exchanges routing
  131.    information containing full AS paths and enforces routing policies
  132.    based on configuration information.
  133.  
  134.    As the Internet has evolved and grown, it has become evident that it
  135.    is soon to face several serious scaling problems. These include:
  136.  
  137.    Exhaustion of the class B network address space. One fundamental
  138.    cause of this problem is the lack of a network class of a size which
  139.    is appropriate for mid-sized organizations; class C, with a maximum
  140.    of 254 host addresses, is too small while class B, which allows up to
  141.    65534 addresses, is too large to be densely populated.  Growth of
  142.    routing tables in Internet routers is beyond the ability of current
  143.    software (and people) to effectively manage.  Eventual exhaustion of
  144.    the 32-bit IP address space.
  145.  
  146.    It has become clear that the first two of these problems are likely
  147.    to become critical within the next one to three years.  Classless
  148.    inter-domain routing (CIDR) attempts to deal with these problems by
  149.    proposing a mechanism to slow the growth of the routing table and the
  150.    need for allocating new IP network numbers. It does not attempt to
  151.    solve the third problem, which is of a more long-term nature, but
  152.    instead endeavors to ease enough of the short to mid-term
  153.    difficulties to allow the Internet to continue to function
  154.    efficiently while progress is made on a longer-term solution.
  155.  
  156.    BGP-4 is an extension of BGP-3 that provides support for routing
  157.    information aggregation and reduction based on the Classless inter-
  158.    domain routing architecture (CIDR) [4].  BGP-4 contains many of the
  159.    features initially put into the multi-protocol ISO IDRP protocol.
  160.    This memo describes the usage of both BGP-4 and IDRP for IP in the
  161.    Internet.
  162.  
  163.    All of the discussions in this paper are based on the assumption that
  164.    the Internet is a collection of arbitrarily connected Autonomous
  165.    Systems. That is, the Internet will be modeled as a general graph
  166.    whose nodes are AS's and whose edges are connections between pairs of
  167.    AS's.
  168.  
  169.    The classic definition of an Autonomous System is a set of routers
  170.    under a single technical administration, using an interior gateway
  171.    protocol and common metrics to route packets within the AS and using
  172.    an exterior gateway protocol to route packets to other AS's. Since
  173.    this classic definition was developed, it has become common for a
  174.    single AS to use several interior gateway protocols and sometimes
  175.    several sets of metrics within an AS. The use of the term Autonomous
  176.    System here stresses the fact that, even when multiple IGPs and
  177.    metrics are used, the administration of an AS appears to other AS's
  178.    to have a single coherent interior routing plan and presents a
  179.  
  180. Expiration Date March 1994                              [Page 3]
  181.  
  182.  
  183. INTERNET DRAFT                                            September 1993
  184. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  185.  
  186.    consistent picture of which networks are reachable through it.
  187.  
  188.    AS's are assumed to be administered by a single administrative
  189.    entity, at least for the purposes of representation of routing
  190.    information to systems outside of the AS.
  191.  
  192.  
  193. 2. BGP Topological Model
  194.  
  195.  
  196.    When we say that a connection exists between two AS's, we mean two
  197.    things:
  198.  
  199.       Physical connection:  There is a shared network between the two
  200.       AS's, and on this shared network each AS has at least one border
  201.       gateway belonging to that AS. Thus the border gateway of each AS
  202.       can forward packets to the border gateway of the other AS without
  203.       resorting to Inter-AS or Intra-AS routing.
  204.  
  205.       BGP connection:  There is a BGP session between BGP speakers in
  206.       each of the AS's, and this session communicates those routes that
  207.       can be used for specific networks via the advertising AS.
  208.       Throughout this document we place an additional restriction on the
  209.       BGP speakers that form the BGP connection: they must themselves
  210.       share the same network that their border gateways share. Thus, a
  211.       BGP session between adjacent AS's requires no support from either
  212.       Inter-AS or Intra-AS routing. Cases that do not conform to this
  213.       restriction fall outside the scope of this document.
  214.  
  215.    Thus, at each connection, each AS has one or more BGP speakers and
  216.    one or more border gateways, and these BGP speakers and border
  217.    gateways are all located on a shared network. Note that BGP speakers
  218.    do not need to be a border gateway, and vice versa. Paths announced
  219.    by a BGP speaker of one AS on a given connection are taken to be
  220.    feasible for each of the border gateways of the other AS on the same
  221.    shared network, i.e. indirect neighbors are allowed.
  222.  
  223.    Much of the traffic carried within an AS either originates or
  224.    terminates at that AS (i.e., either the source IP address or the
  225.    destination IP address of the IP packet identifies a host on a
  226.    network internal to that AS).  Traffic that fits this description is
  227.    called "local traffic". Traffic that does not fit this description is
  228.    called "transit traffic". A major goal of BGP usage is to control the
  229.    flow of transit traffic.
  230.  
  231.    Based on how a particular AS deals with transit traffic, the AS may
  232.    now be placed into one of the following categories:
  233.  
  234.       Stub AS: an AS that has only a single connection to one other AS.
  235.       Naturally, a stub AS only carries local traffic.
  236.  
  237.       Multihomed AS: an AS that has connections to more than one other
  238.       AS, but refuses to carry transit traffic.
  239.  
  240. Expiration Date March 1994                              [Page 4]
  241.  
  242.  
  243. INTERNET DRAFT                                            September 1993
  244. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  245.  
  246.       Transit AS: an AS that has connections to more than one other AS,
  247.       and is designed (under certain policy restrictions) to carry both
  248.       transit and local traffic.
  249.  
  250.    Since a full AS path provides an efficient and straightforward way of
  251.    suppressing routing loops and eliminates the "count-to-infinity"
  252.    problem associated with some distance vector algorithms, BGP imposes
  253.    no topological restrictions on the interconnection of AS's.
  254.  
  255. 3. BGP in the Internet
  256.  
  257.  
  258. 3.1 Topology Considerations
  259.  
  260.  
  261.    The overall Internet topology may be viewed as an arbitrary
  262.    interconnection of transit, multihomed, and stub AS's.  In order to
  263.    minimize the impact on the current Internet infrastructure, stub and
  264.    multihomed AS's need not use BGP.  These AS's may run other protocols
  265.    (e.g., EGP) to exchange reachability information with transit AS's.
  266.    Transit AS's using BGP will tag this information as having been
  267.    learned by some method other than BGP. The fact that BGP need not run
  268.    on stub or multihomed AS's has no negative impact on the overall
  269.    quality of inter-AS routing for traffic that either destined to or
  270.    originated from the stub or multihomed AS's in question.
  271.  
  272.    However, it is recommended that BGP be used for stub and multihomed
  273.    AS's as well. In these situations, BGP will provide an advantage in
  274.    bandwidth and performance over some of the currently used protocols
  275.    (such as EGP).  In addition, this would reduce the need for the use
  276.    of default routes and in better choices of Inter-AS routes for
  277.    multihomed AS's.
  278.  
  279. 3.2 Global Nature of BGP
  280.  
  281.  
  282.    At a global level, BGP is used to distribute routing information
  283.    among multiple Autonomous Systems. The information flows can be
  284.    represented as follows:
  285.  
  286.  
  287.                     +-------+         +-------+
  288.               BGP   |  BGP  |   BGP   |  BGP  |   BGP
  289.            ---------+       +---------+       +---------
  290.                     |  IGP  |         |  IGP  |
  291.                     +-------+         +-------+
  292.  
  293.                     <-AS A-->         <--AS B->
  294.  
  295.  
  296.  
  297.    This diagram points out that, while BGP alone carries information
  298.    between AS's, both BGP and an IGP may carry information across an AS.
  299.    Ensuring consistency of routing information between BGP and an IGP
  300.  
  301.  
  302. Expiration Date March 1994                              [Page 5]
  303.  
  304.  
  305. INTERNET DRAFT                                            September 1993
  306. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  307.  
  308.    within an AS is a significant issue and is discussed at length later
  309.    in Appendix A.
  310.  
  311. 3.3 BGP Neighbor Relationships
  312.  
  313.  
  314.    The Internet is viewed as a set of arbitrarily connected AS's. BGP
  315.    speakers in each AS communicate with each other to exchange network
  316.    reachability information based on a set of policies established
  317.    within each AS. Routers that communicate directly with each other via
  318.    BGP are known as BGP neighbors. BGP neighbors can be located within
  319.    the same AS or in different AS's. For the sake of discussion, BGP
  320.    communications with neighbors in different AS's will be referred to
  321.    as External BGP, and with neighbors in the same AS as Internal BGP.
  322.  
  323.    There can be as many BGP speakers as deemed necessary within an AS.
  324.    Usually, if an AS has multiple connections to other AS's, multiple
  325.    BGP speakers are needed. All BGP speakers representing the same AS
  326.    must give a consistent image of the AS to the outside. This requires
  327.    that the BGP speakers have consistent routing information among them.
  328.    These gateways can communicate with each other via BGP or by other
  329.    means. The policy constraints applied to all BGP speakers within an
  330.    AS must be consistent. Techniques such as using a tagged IGP (see
  331.    A.2.2) may be employed to detect possible inconsistencies.
  332.  
  333.    In the case of External BGP, the BGP neighbors must belong to
  334.    different AS's, but share a common network. This common network
  335.    should be used to carry the BGP messages between them. The use of BGP
  336.    across an intervening AS invalidates the AS path information. An
  337.    Autonomous System number must be used with BGP to specify which
  338.    Autonomous System the BGP speaker belongs to.
  339.  
  340. 4. Requirements for Route Aggregation
  341.  
  342.  
  343.    A conformant BGP implementation is required to have the ability to
  344.    specify when an aggregated route may be generated out of partial
  345.    routing information. For example, a BGP speaker at the border of an
  346.    autonomous system (or group of autonomous systems) must be able to
  347.    generate an aggregated route for a whole set of destination IP
  348.    addresses (in BGP terminology such a set is called the Network Layer
  349.    Reachability Information or NLRI) over which it has administrative
  350.    control, even when not all of them are reachable at the same time.
  351.  
  352.    A conformant implementation is required to have the ability to
  353.    specify how NLRI may be de-aggregated.
  354.  
  355.    A conformant implementation is required to support the following
  356.    options when dealing with overlapping routes:
  357.  
  358.    Install both the less and the more specific routes Install the more
  359.    specific route only Install neither route
  360.  
  361.    A conformant implementation may also support other options when
  362.  
  363. Expiration Date March 1994                              [Page 6]
  364.  
  365.  
  366.  
  367. INTERNET DRAFT                                            September 1993
  368. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  369.  
  370.    dealing with overlapping routes, as specified in Clause 7.16.3.1 of
  371.    [6].
  372.  
  373.    By default a BGP speaker should aggregate NLRI representing subnets
  374.    to the corresponding network.
  375.  
  376.    Injecting NLRI representing arbitrary subnets into BGP without
  377.    aggregation to the corresponding network shall be controlled via
  378.    configuration parameters.
  379.  
  380.    Certain routing policies may depend on the NLRI (e.g. "research"
  381.    versus "commercial"). Therefore, a BGP speaker that performs route
  382.    aggregation should be cognizant, if possible, of potential
  383.    implications on routing policies when aggregating NLRI.
  384.  
  385. 5. Policy Making with BGP
  386.  
  387.  
  388.    BGP provides the capability for enforcing policies based on various
  389.    routing preferences and constraints. Policies are not directly
  390.    encoded in the protocol. Rather, policies are provided to BGP in the
  391.    form of configuration information.
  392.  
  393.    BGP enforces policies by affecting the selection of paths from
  394.    multiple alternatives and by controlling the redistribution of
  395.    routing information.  Policies are determined by the AS
  396.    administration.
  397.  
  398.    Routing policies are related to political, security, or economic
  399.    considerations. For example, if an AS is unwilling to carry traffic
  400.    to another AS, it can enforce a policy prohibiting this. The
  401.    following are examples of routing policies that can be enforced with
  402.    the use of BGP:
  403.  
  404.    A multihomed AS can refuse to act as a transit AS for other AS's.
  405.    (It does so by only advertising routes to networks internal to the
  406.    AS.) A multihomed AS can become a transit AS for a restricted set of
  407.    adjacent AS's, i.e., some, but not all, AS's can use the multihomed
  408.    AS as a transit AS. (It does so by advertising its routing
  409.    information to this set of AS's.) An AS can favor or disfavor the use
  410.    of certain AS's for carrying transit traffic from itself.
  411.  
  412.    A number of performance-related criteria can be controlled with the
  413.    use of BGP:
  414.  
  415.    An AS can minimize the number of transit AS's. (Shorter AS paths can
  416.    be preferred over longer ones.) The quality of transit AS's. If an AS
  417.    determines that two or more AS paths can be used to reach a given
  418.    destination, that AS can use a variety of means to decide which of
  419.    the candidate AS paths it will use. The quality of an AS can be
  420.    measured by such things as diameter, link speed, capacity, tendency
  421.    to become congested, and quality of operation. Information about
  422.    these qualities might be determined by means other than BGP.
  423.    Preference of internal routes over external routes.
  424.  
  425. Expiration Date March 1994                              [Page 7]
  426.  
  427.  
  428.  
  429. INTERNET DRAFT                                            September 1993
  430. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  431.  
  432.    For consistency within an AS, equal cost paths, resulting from
  433.    combinations of policies and/or normal route selection procedures,
  434.    must be resolved in a consistent fashion.
  435.  
  436.    Fundamental to BGP is the rule that an AS advertises to its
  437.    neighboring AS's only those routes that it uses. This rule reflects
  438.    the "hop-by-hop" routing paradigm generally used by the current
  439.    Internet.
  440.  
  441.    IDRP for IP has two features (DIST_LIST_INCL and DIST_LIST_EXCL)
  442.    which allow additional constraints to be placed on the propagation of
  443.    routing information, by restricting the group of AS's which may
  444.    receive certain information.  See Section 10 for further details.
  445.  
  446. 6. Path Selection with BGP
  447.  
  448.    One of the major tasks of a BGP speaker is to evaluate different
  449.    paths to a destination network from its border gateways, select the
  450.    best one, apply appropriate policy constraints, and then advertise it
  451.    to all of its BGP neighbors. The key issue is how different paths are
  452.    evaluated and compared.  In traditional distance vector protocols
  453.    (e.g., RIP) there is only one metric (e.g., hop count) associated
  454.    with a path. As such, comparison of different paths is reduced to
  455.    simply comparing two numbers. A complication in Inter-AS routing
  456.    arises from the lack of a universally agreed-upon metric among AS's
  457.    that can be used to evaluate external paths. Rather, each AS may have
  458.    its own set of criteria for path evaluation.
  459.  
  460.    A BGP speaker builds a routing database consisting of the set of all
  461.    feasible paths and the list of networks reachable through each path.
  462.    For purposes of precise discussion, it's useful to consider the set
  463.    of feasible paths for a given destination network. In many cases, we
  464.    would expect to find only one feasible path. However, when this is
  465.    not the case, all feasible paths should be maintained, as their
  466.    maintenance speeds adaptation to the loss of the primary path. Only
  467.    the primary path at any given time will ever be advertised.
  468.  
  469.    The path selection process can be formalized by defining a partial
  470.    order over the set of all feasible paths to a given destination
  471.    network. One way to define this partial order is to define a function
  472.    that maps each full AS path to a non-negative integer that denotes
  473.    the path's degree of preference. Path selection is then reduced to
  474.    applying this function to all feasible paths and choosing the one
  475.    with the lowest degree of preference.
  476.  
  477.    In actual BGP implementations, the criteria for assigning degree of
  478.    preferences to a path are specified as configuration information.
  479.  
  480.    The process of assigning a degree of preference to a path can be
  481.    based on several sources of information:
  482.  
  483.  
  484.    Information explicitly present in the full AS path.  A combination of
  485.    information that can be derived from the full AS path and information
  486.  
  487. Expiration Date March 1994                              [Page 8]
  488.  
  489.  
  490.  
  491. INTERNET DRAFT                                            September 1993
  492. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  493.  
  494.    outside the scope of BGP (e.g., policy routing constraints provided
  495.    as configuration information).
  496.  
  497.    Possible criteria for assigning a degree of preference to a path are:
  498.  
  499.    AS count. Paths with a smaller AS count are generally better.  Policy
  500.    considerations. BGP supports policy-based routing based on the
  501.    controlled distribution of routing information.  A BGP speaker may be
  502.    aware of some policy constraints (both within and outside of its own
  503.    AS) and do appropriate path selection.  Paths that do not comply with
  504.    policy requirements are not considered further.  Presence or absence
  505.    of a certain AS or set of AS's in the path. By means of information
  506.    outside the scope of BGP, an AS may know some performance
  507.    characteristics (e.g., bandwidth, MTU, intra-AS diameter) of certain
  508.    AS's and may try to avoid or prefer them.  Path origin. A path
  509.    learned entirely from BGP (i.e., whose endpoint is internal to the
  510.    last AS on the path) is generally better than one for which part of
  511.    the path was learned via EGP or some other means.  AS path subsets.
  512.    An AS path that is a subset of a longer AS path to the same
  513.    destination should be preferred over the longer path.  Any problem in
  514.    the shorter path (such as an outage) will also be a problem in the
  515.    longer path.  Link dynamics. Stable paths should be preferred over
  516.    unstable ones. Note that this criterion must be used in a very
  517.    careful way to avoid causing unnecessary route fluctuation.
  518.    Generally, any criteria that depend on dynamic information might
  519.    cause routing instability and should be treated very carefully.
  520.  
  521. 7. Recommended Set of Supported Routing Policies.
  522.  
  523.  
  524.    Policies are provided to BGP in the form of configuration
  525.    information.  This information is not directly encoded in the
  526.    protocol. Therefore, BGP can provide support for very complex routing
  527.    policies. However, it is not required that all BGP implementations
  528.    support such policies.
  529.  
  530.    While we are not attempting to standardize the routing policies that
  531.    must be supported in every BGP implementation, we strongly encourage
  532.    all implementors to support the following set of routing policies:
  533.  
  534.    BGP implementations should allow an AS to control announcements of
  535.    BGP-learned routes to adjacent AS's.  Implementations should support
  536.    such control with at least the granularity of a single network.
  537.    Implementations should also support such control with the granularity
  538.    of an autonomous system, where the autonomous system may be either
  539.    the autonomous system that originated the route, or the autonomous
  540.    system that advertised the route to the local system (adjacent
  541.    autonomous system).  Care must be taken when a BGP speaker selects a
  542.    new route that can't be announced to a particular external peer,
  543.    while the previously selected route was announced to that peer.
  544.    Specifically, the local system must explicitly indicate to the peer
  545.    that the previous route is now infeasible.  BGP implementations
  546.    should allow an AS to prefer a particular path to a destination (when
  547.    more than one path is available).  This function may be implemented
  548.  
  549. Expiration Date March 1994                              [Page 9]
  550.  
  551.  
  552.  
  553. INTERNET DRAFT                                            September 1993
  554. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  555.  
  556.    by allowing system administrators to assign "weights" to AS's, and by
  557.    having the route selection process select a route with the lowest
  558.    "weight" (where "weight" of a route is defined as a sum of "weights"
  559.    of all AS's in the AS_PATH path attribute associated with that
  560.    route).  BGP implementations should allow an AS to ignore routes with
  561.    certain AS's in the AS_PATH path attribute.  Such function can be
  562.    implemented by using the technique outlined in [2], and by assigning
  563.    "infinity" as "weights" for such AS's. The route selection process
  564.    must ignore routes that have "weight" equal to "infinity".
  565.  
  566. 8. Interaction With Other Exterior Routing Protocols
  567.  
  568.  
  569.    This section presents guidelines for routing information exchange
  570.    between BGP and BGP-3 or EGP-2, as well as between BGP-4 and IDRP.
  571.    The suggested guidelines are consistent with the guidelines presented
  572.    in [3], [4], and [5].
  573.  
  574.    The routing information exchange has the following aspects: how a
  575.    route received via EGP2/BGP-3 gets injected into BGP how a route
  576.    received via BGP gets injected into EGP2/BGP-3 how a route received
  577.    via BGP-4 gets injected into IDRP how a route received via IDRP gets
  578.    injected into BGP-4
  579.  
  580.    An AS should advertise a minimal aggregate for its internal networks
  581.    with respect to the amount of address space that it is actually
  582.    using.  This can be used by administrators of non-BGP AS's to
  583.    determine how many routes to explode from a single aggregate.
  584.  
  585. 8.1 Exchanging Information With EGP2
  586.  
  587.  
  588.    The following guidelines are suggested for exchanging routing
  589.    information between BGP and EGP2.
  590.  
  591.    To provide for graceful migration, a BGP speaker may participate in
  592.    EGP2 as well as in BGP. Thus, a BGP speaker may receive IP
  593.    reachability information by means of EGP2 as well as by means of BGP.
  594.    It is strongly recommended that the exchange of routing information
  595.    via EGP2 between a BGP speaker participating in BGP and a pure EGP2
  596.    speaker occur only at Autonomous System boundaries.
  597.  
  598.    The information received by EGP2 can be injected into BGP-4 with the
  599.    ORIGIN path attribute set to 1.  It can likewise be injected into
  600.    IDRP with the EXT_INFO path attribute.
  601.  
  602.    Likewise, the information received via BGP can be injected into EGP2.
  603.    In the latter case, however, one needs to be aware of the potential
  604.    information explosion when a given IP prefix received from BGP
  605.    denotes a set of consecutive A/B/C class networks.  Injection of BGP
  606.    received NLRI that denotes IP subnets requires the BGP speaker to
  607.    inject the corresponding network into EGP2.
  608.  
  609.    The local system shall provide mechanisms to control the exchange of
  610.  
  611. Expiration Date March 1994                             [Page 10]
  612.  
  613.  
  614.  
  615. INTERNET DRAFT                                            September 1993
  616. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  617.  
  618.    reachability information between EGP2 and BGP.  Specifically, a
  619.    conformant implementation is required to support all of the following
  620.    options when injecting BGP received reachability information into
  621.    EGP2:
  622.  
  623.    inject default only (0.0.0.0); no export of any other NLRI allow
  624.    controlled deaggregation, but only of specific routes; allow export
  625.    of non-aggregated NLRI allow export of only non-aggregated NLRI
  626.  
  627.    Additional constraints on injecting information received via IDRP
  628.    into EGP2 are listed in Section 8.4.  Additional constraints on
  629.    injecting information received via BGP-4 into EGP2 are listed in
  630.    Section 8.5.
  631.  
  632. 8.2 Exchanging information with BGP-3
  633.  
  634.  
  635.    The following guidelines are suggested for exchanging routing
  636.    information between BGP and BGP-3.
  637.  
  638.    To provide for graceful migration, a BGP speaker may participate in
  639.    BGP-3 as well as in BGP.  Thus, a BGP speaker may receive IP
  640.    reachability information by means of BGP-3 as well as by means of
  641.    BGP.  It is strongly recommended that the exchange of routing
  642.    information via BGP-3 between a BGP speaker participating in BGP-3
  643.    and a pure BGP-3 speaker occur only at Autonomous System boundaries.
  644.  
  645.    When injecting BGP-3 routes into BGP-4, the AS_SEQUENCE information
  646.    shall be injected as an AS_SET.  For IDRP, the AS_SEQUENCE
  647.    information shall be injected as an RD_SET within the RD_PATH
  648.    attribute.
  649.  
  650.    A BGP speaker may inject the information received by BGP-4 into BGP-3
  651.    as follows.
  652.  
  653.    If an AS_PATH attribute of a BGP-4 route carries AS_SET path
  654.    segments, then the AS_PATH attribute of the BGP-3 route shall be
  655.    constructed by treating the AS_SET segments as AS_SEQUENCE segments,
  656.    with the resulting AS_PATH being a single AS_SEQUENCE. While this
  657.    procedure loses set/sequence information, it doesn't affect
  658.    protection for routing loops suppression.  It may affect policies if
  659.    they are based on the content or ordering of the AS_PATH attribute.
  660.  
  661.    A BGP speaker may inject the information received by IDRP into BGP-3
  662.    as follows.
  663.  
  664.    IDRP's equivalent for the AS_PATH attribute is RD_PATH path
  665.    attribute, where RD stands for Routing Domain.  A Routing Domain has
  666.    an identifier which for IDRP for IP is a fixed prefix catenated with
  667.    the AS number.  Given this translation, as defined in the "IDRP for
  668.    IP" document, the IDRP RD_PATH information containing RD_SEQUENCEs
  669.    and RD_SETs is translated into BGP-3 AS_SEQUENCES attribute in the
  670.    same way BGP-4's AS_SEQUENCEs and AS-SETs are.  The resulting BGP-3
  671.    AS_PATH attribute contains all the domains listed in the RD_PATH
  672.  
  673.  
  674. Expiration Date March 1994                             [Page 11]
  675.  
  676.  
  677.  
  678. INTERNET DRAFT                                            September 1993
  679. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  680.  
  681.    attribute.  Again, this does not affect loop suppression, but may
  682.    affect policies.
  683.  
  684.    While injecting BGP derived NLRI into BGP-3, one needs to be aware of
  685.    the potential information explosion when a given IP prefix denotes a
  686.    set of consecutive A/B/C class networks. Injection of BGP derived
  687.    NLRI that denotes IP subnets requires the BGP speaker to inject the
  688.    corresponding network into BGP-3. The local system shall provide
  689.    mechanisms to control the exchange of routing information between
  690.    BGP-3 and BGP.  Specifically, a conformant implementation is required
  691.    to support all of the following options when injecting BGP received
  692.    routing information into BGP-3:
  693.  
  694.    inject default only (0.0.0.0), no export of any other NLRI allow
  695.    controlled deaggregation, but only of specific routes; allow export
  696.    of non-aggregated NLRI allow export of only non-aggregated NLRI
  697.  
  698.    Additional constraints on injecting information received via IDRP
  699.    into BGP-3 are listed in Section 8.4.  Additional constraints on
  700.    injecting information received via BGP-4 into BGP-3 are listed in
  701.    Section 8.5.
  702.  
  703. 8.3 Exchanging Information Between IDRP and BGP-4
  704.  
  705.  
  706.    To provide for graceful migration, an IDRP speaker may participate in
  707.    BGP-4. Thus, an IDRP speaker may receive IP reachability information
  708.    by means of BGP-4, as well as by means of IDRP.  If IDRP for IP and
  709.    BGP-4 routers restrict themselves to the set of functions which is
  710.    common to both protocols, translation between the protocols can be
  711.    done.  Within these restrictions, routers can participate in both
  712.    IDRP and BGP-4 conversations on domain boundaries, and within routing
  713.    domains.
  714.  
  715.    When passing a BGP-4 route with the ATOMIC_AGGREGATE path attribute
  716.    to IDRP, the IDRP for IP ATOMIC_AGGREGATE shall be included in the
  717.    IDRP route.  The ATOMIC_AGGREGATE attribute is defined in [7].
  718.  
  719.    Note that any IDRP for IP router receiving a route with the
  720.    ATOMIC_AGGREGATE option shall not deaggregate that route.
  721.  
  722.    Also note that any IDRP router not recognizing the ATOMIC_AGGREGATE
  723.    option shall set the Partial bit in the Flag field of the attribute
  724.    to 1, as required by clause 7.11.1.a in [6].
  725.  
  726.    In exporting reachability information from IDRP for IP to BGP-4, if
  727.    the IDRP for IP ATOMIC_AGGREGATE attribute is present and the Partial
  728.    bit is set to 0, the BGP-4 ATOMIC_AGGREGATE attribute shall be
  729.    included in the BGP-4 route.  If the IDRP for IP ATOMIC_AGGREGATE
  730.    attribute is present and the Partial bit is set to 1, the BGP-4
  731.    ORIGIN attribute shall be set to INCOMPLETE.
  732.  
  733.    The following table specifies mapping between BGP-4 and IDRP for IP
  734.    path attributes.
  735.  
  736. Expiration Date March 1994                             [Page 12]
  737.  
  738.  
  739.  
  740. INTERNET DRAFT                                            September 1993
  741. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  742.  
  743.                          BGP4           IDRP
  744.                         -------------------------------
  745.  
  746.                         ORIGIN          EXT_INFO
  747.  
  748.                         AS_PATH         RD_PATH
  749.  
  750.                         NEXT_HOP        NEXT_HOP
  751.  
  752.                         MULTI_EXTI_DISC MULTI_EXIT_DISC
  753.  
  754.                         LOC_PREF        ROUTE_SEPARATOR
  755.  
  756.  
  757.  
  758.    Additional constraints on injecting information received via IDRP
  759.    into BGP-4 are listed in Section 8.4.
  760.  
  761. 8.4 Additional Constraints on Exchange of IDRP Routes
  762.  
  763.  
  764.    The following IDRP attributes cannot be passed into EGP2, BGP-3, or
  765.    BGP-4:
  766.  
  767.    CAPACITY RD-HOP-COUNT
  768.  
  769.    However, IDRP routes with these attributes can be passed into EGP2,
  770.    BGP-3, or BGP-4 after stripping the attributes.
  771.  
  772.    IDRP routes with the following path attributes cannot be passed into
  773.    BGP-3, BGP-4, and EGP2:
  774.  
  775.    DIST_LIST_INCL DIST_LIST_EXCL HIERARCHICAL_RECORDING TRANSIT DELAY
  776.    RESIDUAL_ERROR EXPENSE LOCALLY DEFINED QoS SECURITY PRIORITY
  777.  
  778.    When passing a route received via EGP2 or a route received via BGP-3
  779.    or BGP-4, such that the value of the ORIGIN attribute of the route is
  780.    anything but IGP, to IDRP, the corresponding IDRP route shall have
  781.    the EXT_INFO path attribute.  If an IDRP route carries EXT_INFO path
  782.    attribute then the corresponding BGP-3 or BGP-4 route shall have
  783.    value of its ORIGIN attribute set to INCOMPLETE.
  784.  
  785.    When passing a BGP-3 or BGP-4 route to IDRP, the IDRP RD-HOP-COUNT
  786.    attribute shall be constructed by counting the number of ASs in the
  787.    AS-PATH attribute of the route.
  788.  
  789.    If an IDRP route carries ENTRY_SEQ or ENTRY_SET path segments, then
  790.    before passing this route to BGP-3 or BGP-4 the BIS shall assume that
  791.    the route exited all the confederations denoted in ENTRY_SET or
  792.    ENTRY_SEQ and update the RD_PATH of the route accordingly.
  793.  
  794.  
  795.  
  796.  
  797.  
  798. Expiration Date March 1994                             [Page 13]
  799.  
  800.  
  801.  
  802. INTERNET DRAFT                                            September 1993
  803. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  804.  
  805. 8.5 Additional Constrains on Exchange of BGP-4 Routes
  806.  
  807.  
  808.    The following BGP-4 attribute can not be passed into EGP2, BGP-3, or
  809.    IDRP:
  810.  
  811.    AGGREGATOR
  812.  
  813.    However, BGP-4 routes with this attribute can be passed into IDRP.
  814.  
  815.    A route that carries the BGP-4 ATOMIC_AGGREGATE path attribute shall
  816.    not be exported into EGP2 or BGP-3, unless such export can be
  817.    accomplished without deaggregating the NLRI of the route.
  818.  
  819. 9. Operations over Switched Virtual Circuits
  820.  
  821.  
  822.    When using BGP over Switched Virtual Circuit (SVC) subnetworks it may
  823.    be desirable to minimize traffic generated by BGP. Specifically, it
  824.    may be desirable to eliminate traffic associated with periodic
  825.    KEEPALIVE messages.  BGP includes a mechanism for operation over
  826.    switched virtual circuit (SVC) services which avoids keeping SVCs
  827.    permanently open and allows it to eliminate periodic sending of
  828.    KEEPALIVE messages.
  829.  
  830.    This section describes how to operate without periodic KEEPALIVE
  831.    messages to minimize SVC usage when using an intelligent SVC circuit
  832.    manager.  This scheme may also be used on "permanent" circuits, which
  833.    support a feature like link quality monitoring or echo request to
  834.    determine the status of link connectivity.
  835.  
  836.    The mechanism described in this section is suitable only between BGP
  837.    speakers that are directly connected over a common virtual circuit.
  838.  
  839. 9.1 Establishing a BGP Connection
  840.  
  841.  
  842.    The feature is selected by specifying zero Hold Time in the OPEN
  843.    message.
  844.  
  845. 9.2 Circuit Manager Properties
  846.  
  847.  
  848.    The circuit manager must have sufficient functionality to be able to
  849.    compensate for the lack of periodic KEEPALIVE messages:
  850.  
  851.    It must be able to determine link layer unreachability within a
  852.    bounded time of the occurance of such a failure.  On determining
  853.    unreachability it should: start a configurable dead timer (comparable
  854.    to a typical Hold timer value).  attempt to re-establish the Link
  855.    Layer connection.
  856.  
  857.    If the dead timer expires it should: send an internal circuit DEAD
  858.    indication to TCP (if used with BGP-4) or to the IDRP Finite State
  859.  
  860. Expiration Date March 1994                             [Page 14]
  861.  
  862.  
  863.  
  864. INTERNET DRAFT                                            September 1993
  865. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  866.  
  867.  
  868.    Machine (if used with IDRP for IP) If the connection is re-
  869.    established before the dead timer expires it should: cancel the dead
  870.    timer.  If the connection is re-established after the dead timer has
  871.    expired (that is, after a DEAD indication has been sent) it should:
  872.    send an internal circuit UP indication to TCP (if used with BGP-4) or
  873.    to the IDRP Finite State Machine (if used with IDRP for IP).
  874.  
  875.  
  876. 9.3 TCP Properties
  877.  
  878.  
  879.    A small modification must be made to TCP to process internal
  880.    notifications from the circuit manager: DEAD: Flush transmit queue
  881.    and abort TCP connection.  UP: Transmit any queued data or allow an
  882.    outgoing TCP call to proceed.
  883.  
  884. 9.4 IDRP Finite State Machine Properties
  885.  
  886.  
  887.    A small modification must be made to the IDRP Finite State Machine to
  888.    process internal notifications from the circuit manager: DEAD:
  889.    Generate the DEACTIVATE event UP: Generate the ACTIVATE event
  890.  
  891. 9.5 Combined Properties
  892.  
  893.  
  894.    Some implementations may not be able to guarantee that the BGP
  895.    process and the circuit manager will operate as a single entity; i.e.
  896.    they can have a separate existence when the other has been stopped or
  897.    has crashed.
  898.  
  899.    If this is the case, a periodic two-way poll between the BGP process
  900.    and the circuit manager should be implemented.  If the BGP process
  901.    discovers the circuit manager has gone away it should close all
  902.    relevant TCP connections in the case of BGP-4 or close all relevant
  903.    peer sessions in the case of IDRP.  If the circuit manager discovers
  904.    the BGP process has gone away it should close all its connections
  905.    associated with the BGP process and reject any further incoming
  906.    connections.
  907.  
  908. 10. IDRP for IP Differences
  909.  
  910.  
  911.    The additional attributes and protocol semantics IDRP contains
  912.    besides those in BGP-4 fall into three categories:  QoS related,
  913.    Distribution List related, and Routing Domain Confederations related.
  914.  
  915.    The QoS related attributes can be thought of as an extension of the
  916.    TOS functions already defined in IP.  These functions have been left
  917.    by IDRP for IP for future study and experimentation.  Anyone
  918.    interested in IDRP's QoS features should contact the BGP/IDRP for IP
  919.    working groups.
  920.  
  921.    The Distribution List attributes are DIST_LIST_INCL and
  922.  
  923. Expiration Date March 1994                             [Page 15]
  924.  
  925.  
  926. INTERNET DRAFT                                            September 1993
  927. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  928.  
  929.    DIST_LIST_EXCL.  Their function can be described as follows:  BGP
  930.    speakers receive information from BGP speakers in other AS's, which
  931.    we call the "upstream" AS's.  They then select routes from this
  932.    information and propagate them to other AS's, which we call the
  933.    "downstream" AS's.  The distribution list attributes provide
  934.    mechanisms for the router originating some reachability information
  935.    (or any router downstream of it) to constrain the downstream
  936.    propagation of that information.  If distribution list attributes are
  937.    included, downstream AS's are required to restrict distribution of
  938.    the routing information -- in the case of DIST_LIST_INCL, the routing
  939.    information may only be distributed to the specified set of AS's, and
  940.    in the case of DIST_LIST_EXCL, the routing information my be
  941.    distributed to any AS's but the specified set.  If no distribution
  942.    list attributes are included, the information may be distributed
  943.    without constraint.
  944.  
  945.    Routing Domain Confederations is a mechanism to group together
  946.    routing domains with compatible policies, in effect providing
  947.    "aggregation" of Routing Domains.  By using RDCs, AS paths can be
  948.    compacted considerably.
  949.  
  950.    With a Confederation, several AS's can be grouped together.  From the
  951.    point of view of AS's external to the Confederation, the AS path
  952.    information (RD_PATH) can be replaced by a single identifier, the RDC
  953.    identifier.  For example, if 10 associated AS's containing 30 IP
  954.    networks decide to form a Confederation (they might be the members of
  955.    an academic consortium, for example), they could advertise all 30 of
  956.    their networks with a single entry in the RD_PATH, abstracting the
  957.    internal topology of their confederation.
  958.  
  959. 11. Conclusion
  960.  
  961.  
  962.    The BGP protocols, BGP-4 and IDRP, provide a high degree of control
  963.    and flexibility for doing interdomain routing while enforcing policy
  964.    and performance constraints and avoiding routing loops. The
  965.    guidelines presented here will provide a starting point for using BGP
  966.    to provide more sophisticated and manageable routing in the Internet
  967.    as it grows.
  968.  
  969. Appendix A. The Interaction of BGP and an IGP
  970.  
  971.  
  972.    This section outlines methods by which BGP can exchange routing
  973.    information with an IGP. The methods outlined here are not proposed
  974.    as part of the standard BGP usage at this time.  These methods are
  975.    outlined for information purposes only.  Implementors may want to
  976.    consider these methods when importing IGP information.
  977.  
  978.    This is general information that applies to any generic IGP.
  979.    Interaction between BGP and any specific IGP is outside the scope of
  980.    this section.  Methods for specific IGP's should be proposed in
  981.    separate documents.  Methods for specific IGP's could be proposed for
  982.    standard usage in the future.
  983.  
  984. Expiration Date March 1994                             [Page 16]
  985.  
  986.  
  987. INTERNET DRAFT                                            September 1993
  988. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  989.  
  990. Overview
  991.  
  992.  
  993.    By definition, all transit AS's must be able to carry traffic which
  994.    originates from and/or is destined to locations outside of that AS.
  995.    This requires a certain degree of interaction and coordination
  996.    between BGP and the Interior Gateway Protocol (IGP) used by that
  997.    particular AS. In general, traffic originating outside of a given AS
  998.    will pass through both interior gateways (gateways that support the
  999.    IGP only) and border gateways (gateways that support both the IGP and
  1000.    BGP). All interior gateways receive information about external routes
  1001.    from one or more of the border gateways of the AS via the IGP, unless
  1002.    encapsulation is used (see Section A.2.3).
  1003.  
  1004.    Depending on the mechanism used to propagate BGP information within a
  1005.    given AS, special care must be taken to ensure consistency between
  1006.    BGP and the IGP, since changes in state are likely to propagate at
  1007.    different rates across the AS. There may be a time window between the
  1008.    moment when some border gateway (A) receives new BGP routing
  1009.    information which was originated from another border gateway (B)
  1010.    within the same AS, and the moment the IGP within this AS is capable
  1011.    of routing transit traffic to that border gateway (B). During that
  1012.    time window, either incorrect routing or "black holes" can occur.
  1013.  
  1014.    In order to minimize such routing problems, border gateway (A) should
  1015.    not advertise a route to some exterior network X via border gateway
  1016.    (B) to all of its BGP neighbors in other AS's until all the interior
  1017.    gateways within the AS are ready to route traffic destined to X via
  1018.    the correct exit border gateway (B). In other words, interior routing
  1019.    should converge on the proper exit gateway before/advertising routes
  1020.    via that exit gateway to other AS's.
  1021.  
  1022. A.2 Methods for Achieving Stable Interactions
  1023.  
  1024.  
  1025.    The following discussion outlines several techniques capable of
  1026.    achieving stable interactions between BGP and the IGP within an
  1027.    Autonomous System.
  1028.  
  1029. A.2.1 Propagation of BGP Information via the IGP
  1030.  
  1031.  
  1032.    While BGP can provide its own mechanism for carrying BGP information
  1033.    within an AS, one can also use an IGP to transport this information,
  1034.    as long as the IGP supports complete flooding of routing information
  1035.    (providing the mechanism to distribute the BGP information) and one
  1036.    pass convergence (making the mechanism effectively atomic). If an IGP
  1037.    is used to carry BGP information, then the period of
  1038.    desynchronization described earlier does not occur at all, since BGP
  1039.    information propagates within the AS synchronously with the IGP, and
  1040.    the IGP converges more or less simultaneously with the arrival of the
  1041.    new routing information. Note that the IGP only carries BGP
  1042.    information and should not interpret or process this information.
  1043.  
  1044.  
  1045. Expiration Date March 1994                             [Page 17]
  1046.  
  1047.  
  1048. INTERNET DRAFT                                            September 1993
  1049. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  1050.  
  1051. A.2.2  Tagged Interior Gateway Protocol
  1052.  
  1053.  
  1054.    Certain IGPs can tag routes exterior to an AS with the identity of
  1055.    their exit points while propagating them within the AS. Each border
  1056.    gateway should use identical tags for announcing exterior routing
  1057.    information (received via BGP) both into the IGP and into Internal
  1058.    BGP when propagating this information to other border gateways within
  1059.    the same AS. Tags generated by a border gateway must uniquely
  1060.    identify that particular border gateway--different border gateways
  1061.    must use different tags.
  1062.  
  1063.    All Border Gateways within a single AS must observe the following two
  1064.    rules:
  1065.  
  1066.  
  1067.    Information received via Internal BGP by a border gateway A declaring
  1068.    a network to be unreachable must immediately be propagated to all of
  1069.    the External BGP neighbors of A.  Information received via Internal
  1070.    BGP by a border gateway A about a reachable network X cannot be
  1071.    propagated to any of the External BGP neighbors of A unless/until A
  1072.    has an IGP route to X and both the IGP and the BGP routing
  1073.    information have identical tags.
  1074.  
  1075.    These rules guarantee that no routing information is announced
  1076.    externally unless the IGP is capable of correctly supporting it. It
  1077.    also avoids some causes of "black holes".
  1078.  
  1079.    One possible method for tagging BGP and IGP routes within an AS is to
  1080.    use the IP address of the exit border gateway announcing the exterior
  1081.    route into the AS. In this case the "gateway" field in the BGP UPDATE
  1082.    message is used as the tag.
  1083.  
  1084.    An alternate method for tagging BGP and IGP routes is to have BGP and
  1085.    the IGP agree on a router ID.  In this case, the router ID is
  1086.    available to all BGP (version 3 or higher) speakers.  Since this ID
  1087.    is already unique it can be used directly as the tag in the IGP.
  1088.  
  1089. A.2.3 Encapsulation
  1090.  
  1091.  
  1092.    Encapsulation provides the simplest (in terms of the interaction
  1093.    between the IGP and BGP) mechanism for carrying transit traffic
  1094.    across the AS. In this approach, transit traffic is encapsulated
  1095.    within an IP datagram addressed to the exit gateway. The only
  1096.    requirement imposed on the IGP by this approach is that it should be
  1097.    capable of supporting routing between border gateways within the same
  1098.    AS.
  1099.  
  1100.    The address of the exit gateway A for some exterior network X is
  1101.    specified in the BGP identifier field of the BGP OPEN message
  1102.    received from gateway A via Internal BGP by all other border gateways
  1103.    within the same AS. In order to route traffic to network X, each
  1104.    border gateway within the AS encapsulates it in datagrams addressed
  1105.  
  1106.  
  1107. Expiration Date March 1994                             [Page 18]
  1108.  
  1109.  
  1110.  
  1111. INTERNET DRAFT                                            September 1993
  1112. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  1113.  
  1114.    to gateway A. Gateway A then performs decapsulation and forwards the
  1115.    original packet to the proper gateway in another AS.
  1116.  
  1117.    Since encapsulation does not rely on the IGP to carry exterior
  1118.    routing information, no synchronization between BGP and the IGP is
  1119.    required.
  1120.  
  1121.    Some means of identifying datagrams containing encapsulated IP, such
  1122.    as an IP protocol type code, must be defined if this method is to be
  1123.    used.
  1124.  
  1125.    Note that, if a packet to be encapsulated has length that is very
  1126.    close to the MTU, that packet would be fragmented at the gateway that
  1127.    performs encapsulation.
  1128.  
  1129. A.2.4  Pervasive BGP
  1130.  
  1131.  
  1132.    If all routers in an AS are BGP speakers, then there is no need to
  1133.    have any interaction between BGP and an IGP.  In such cases, all
  1134.    routers in the AS already have full information of all BGP routes.
  1135.    The IGP is then only used for routing within the AS, and no BGP
  1136.    routes are imported into the IGP.
  1137.  
  1138.    For routers to operate in this fashion, they must be able to perform
  1139.    a recursive lookup in their routing table.  The first lookup will use
  1140.    a BGP route to establish the exit router, while the second lookup
  1141.    will determine the IGP path to the exit router.
  1142.  
  1143.    Since the IGP carries no external information in this scenario, all
  1144.    routers in the AS will have converged as soon as all BGP speakers
  1145.    have new information about this route.  Since there is no need to
  1146.    delay for the IGP to converge, an implementation may advertise these
  1147.    routes without further delay due to the IGP.
  1148.  
  1149. A.2.5  Other Cases
  1150.  
  1151.  
  1152.    There may be AS's with IGPs which can neither carry BGP information
  1153.    nor tag exterior routes (e.g., RIP). In addition, encapsulation may
  1154.    be either infeasible or undesirable. In such situations, the
  1155.    following two rules must be observed:
  1156.  
  1157.    Information received via Internal BGP by a border gateway A declaring
  1158.    a network to be unreachable must immediately be propagated to all of
  1159.    the External BGP neighbors of A.  Information received via Internal
  1160.    BGP by a border gateway A about a reachable network X cannot be
  1161.    propagated to any of the External BGP neighbors of A unless A has an
  1162.    IGP route to X and sufficient time has passed for the IGP routes to
  1163.    have converged.
  1164.  
  1165.    The above rules present necessary (but not sufficient) conditions for
  1166.    propagating BGP routing information to other AS's. In contrast to
  1167.    tagged IGPs, these rules cannot ensure that interior routes to the
  1168.  
  1169. Expiration Date March 1994                             [Page 19]
  1170.  
  1171.  
  1172.  
  1173. INTERNET DRAFT                                            September 1993
  1174. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  1175.  
  1176.    proper exit gateways are in place before propagating the routes to
  1177.    other AS's.
  1178.  
  1179.    If the convergence time of an IGP is less than some small value X,
  1180.    then the time window during which the IGP and BGP are unsynchronized
  1181.    is less than X as well, and the whole issue can be ignored at the
  1182.    cost of transient periods (of less than length X) of routing
  1183.    instability. A reasonable value for X is a matter for further study,
  1184.    but X should probably be less than one second.
  1185.  
  1186.    If the convergence time of an IGP cannot be ignored, a different
  1187.    approach is needed. Mechanisms and techniques which might be
  1188.    appropriate in this situation are subjects for further study.
  1189.  
  1190. References
  1191.  
  1192.  
  1193.    [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4),
  1194.    Internet Draft, cisco Systems, T.J. Watson Research Center, IBM
  1195.    Corp., September 1993.
  1196.  
  1197.    [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
  1198.    Merit/NSFNET, June 1989.
  1199.  
  1200.    [3] Fuller, V., Li, T., Yu, J., Varadhan, K., "Supernetting: an
  1201.    Address Assignment and Aggregation Strategy", RFC1519, September
  1202.    1993.
  1203.  
  1204.    [4] Rekhter, Y., Li, T., "An Architecture for IP address Allocation
  1205.    with CIDR", RFC1518, September 1993
  1206.  
  1207.    [5] Rekhter, Y., Topolcic, C. "Exchanging Routing Information Across
  1208.    Provider/Subscriber Boundaries in the CIDR Environment", RFC1520,
  1209.    September 1993
  1210.  
  1211.    [6] ISO/IEC IS 10747 - Information Processing Systems -
  1212.    Telecommunications and Information Exchange between Systems -
  1213.    Protocol for Exchange of Inter-domain Routeing Information among
  1214.    Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993.
  1215.  
  1216.    [7] Hares, S., Scudder, J., "IDRP for IP", Internet Draft, Merit
  1217.    Network Inc., September 1993.
  1218.  
  1219.    [8] ISO/IEC JTC 1 "Protocol for Exchanging of Inter-Domain Routeing
  1220.    Information among Intermediate Systems to Support Forwarding of ISO
  1221.    8473 PDUs", IS10747 1993
  1222.  
  1223. Security Considerations
  1224.  
  1225.  
  1226.    Security issues are not discussed in this memo.
  1227.  
  1228.  
  1229.  
  1230. Expiration Date March 1994                             [Page 20]
  1231.  
  1232.  
  1233.  
  1234. INTERNET DRAFT                                            September 1993
  1235. draft-ietf-bgp-idrp-idrp-usage-01.txt 
  1236.  
  1237. Authors' Addresses
  1238.  
  1239.  
  1240.    Yakov Rekhter
  1241.    T.J. Watson Research Center IBM Corporation
  1242.    P.O. Box 218
  1243.    Yorktown Heights, NY 10598
  1244.  
  1245.    Phone:  (914) 945-3896
  1246.    EMail: yakov@watson.ibm.com
  1247.  
  1248.    Susan Hares
  1249.    Merit, Inc
  1250.    1071 Beal Avenue
  1251.    Ann Arbor, MI 4810x
  1252.  
  1253.    Phone: (313)936-2095
  1254.    Email: skh@merit.edu
  1255.  
  1256.  
  1257.    IETF BGP WG mailing list: bgp@ans.net
  1258.    To be added: bgp-request@ans.net
  1259.  
  1260.    IETF IDRP for IP WG mailing list: idrp-for-ip@merit.edu
  1261.    To be added: idrp-request@merit.edu
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292. Expiration Date March 1994                             [Page 21]
  1293.  
  1294.  
  1295.